---
author: hongbo
date: "2018-12-05"
previewImg:
badge: release
title: BuckleScript 4.0.8 (Part One)
description: |
---

## New Release

Today we released version 4.0.8 of `bs-platform`.
A detailed list of changes is available
[here](https://github.com/BuckleScript/bucklescript/blob/master/Changes.md#408).

Most user-facing changes are bug fixes and small enhancements, while quite a
lot of work has been done behind the scenes towards the more fundamental
improvements coming down the line. This blog post refers to the BuckleScript
runtime and some of the work we are doing to improve it.

The design goal of BuckleScript is to make the runtime as small as possible.
This runtime is divided into two parts: the C shims, and the fundamental
language feature support.

The C shims are not a strict runtime requirement: in the native backend, the
functions are implemented in C, but in BuckleScript this isn't necessary. We
can either implement the C shims in a polyfill style or we can just implement
them in OCaml and compile via BuckleScript. Recently, we have been shifting
more and more work from the runtime to the normal OCaml stdlib by patching it
with conditional compilation. The benefit is obvious – they are just normal
functions which do not need special compiler support – but the downside is that
we might need to make more patches to the libraries which use C functions, but
considering the more challenging part of maintaining the patches to the
compiler, we think such overhead is worthwhile.

If we ignore the C shims, the BuckleScript runtime is very small, and it is
pretty easy for experienced BuckleScript programmers to write runtime-free code
which generates standalone JS code. Such code could include supporting curried
calling conventions, encoding of OCaml ADT, etc.

The BuckleScript runtime is written in BuckleScript itself. The benefit of this
is that it is much more maintainable than implementing in JS itself, and it is
easier to keep some invariants when crossing the boundary between the runtime
and the stdlib. For example, we don't need to worry about the consistency of
the runtime encoding of `type tuple` in BuckleScript, since the runtime is also
implemented in BuckleScript itself, and we get three output modules for free
thanks to this "dogfooding".

However, this makes the build system pretty complicated and fragile, and the
dependencies between each module are mostly hard coded. Even worse, this
introduces a hard dependency between the normal libraries and the runtime
binary artifacts.

In particular, one
[issue](https://github.com/BuckleScript/bucklescript/issues/2772) we want to
address is to make the BuckleScript toolchain lightweight. We will continue to
implement the BuckleScript runtime by using BuckleScript itself, but we want to
get rid of dependencies like [the support for
exceptions](https://github.com/BuckleScript/bucklescript/issues/3164). In the
end, installation will no longer involve building the runtime: BuckleScript
will simply be a bunch of generated JS files, so the complexity of the build
system will not impact users at all. This is quite important given that we are
committed to supporting Windows.

In the future, we will therefore be able to distribute the runtime as a normal
JS library, and the BuckleScript user will only need the binary compiler and a
small set of JS files. They will be able to use stdlib, Belt or anything else.

To get rid of such dependencies between stdlib and the runtime, we are going to
introduce a breaking change in the future. In hindsight, our support for
catching JS exceptions exposed the concrete representation of the exception
encoding, in particular:

```ocaml
match ... with
| OCamlException exn -> ..
| Js.Exn.Error e -> ...
```

In this release, we introduced a function to avoid exposing such exception constructors:

```ocaml
match ... with
| OCamlException exn -> ...
| e ->
    match Js.asJsExn e with
    | Some jserror -> ..
    | None -> ...
```

We encourage you to make such changes yourself to future-proof your codebases.

Oh and by the way, one side effect of this refactoring of the BuckleScript
runtime is that the compilation does not require reading of the generated
`.cm*` files, which means faster compilation :)
